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ABSTRACT: 

A  declarative  hierarchical  notation  is  introduced  that 
allows  the  parametric  representation  of  entire  families 
of  VLSI  circuits.  Layout,  schematic  diagrams  and  net¬ 
work  structure  are  all  accommodated  by  the  notation 
in  a  way  that  emphasizes  common  elements.  The  no¬ 
tation  is  the  basis  of  a  structured  environment  for  de¬ 
veloping  design  generators  as  well  as  capturing  design 
expertise. 


1  Introduction 

The  application  of  full  custom  integrated  circuit  design 
to  architectural  problems  requires  a  multitude  of  CAD 
techniques.  Not  only  does  the  designer  have  to  specify 
and  simulate  networks  of  components,  but  he  also  has 
to  deal  with  the  physical  layout  of  those  components. 
It  seems  apparent  that  the  sheer  volume  of  circuitry  re¬ 
quired  for  even  the  simplest  architectures  mandates  an 
approach  that  utilizes  previously  captured  circuit  de¬ 
signs.  One  method  of  capturing  expertise  about  entire 
families  of  circuit  design  is  through  the  use  of  design 
generators. 

We  define  a  design  generator  as  a  program  that 
produces  instances  from  a  family  of  circuit  designs. 
The  input  is  a  problem-specific  set  of  parameters;  the 
most  common  output  is  the  layout  of  the  mask  layers. 
Several  systems  have  been  developed  for  the  construc¬ 
tion  of  layout  generators  (e.g.  [Bamji  85]). 

Although  the  layout  is  the  final  means  of  specify¬ 
ing  a  circuit,  it  is  simply  too  detailed  and  technology- 
dependent  to  efficiently  capture  design  expertise. 
Other  more  abstract  views  or  representations  are  nec¬ 
essary  if  one  wishes  to  capture  the  design  at  a  higher 
level  and  could  likewise  aid  the  user  of  the  generator 
as  he  constructs  a  complex  design  from  a  number  of 
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generated  modules.  A  behavioral  model  of  the  gen¬ 
erated  circuit,  for  example,  could  be  used  in  a  func¬ 
tional  simulator.  A  network  of  devices  could  be  used 
in  a  switch-level  or  analog  simulator.  A  schematic  di¬ 
agram  could  be  used  for  documentation  purposes. 

Our  approach  to  developing  a  design  generator 
environment  is  one  that  will  support  such  multiple  rep¬ 
resentations.  In  order  to  efficiently  capture  design  ex¬ 
pertise,  the  correspondence  between  such  representa¬ 
tions  will  be  made  evident. 


1.1  Design  Generator  Model 

Given  the  need  to  support  multiple  representations, 
what  might  an  ideal  environment  for  developing  gen¬ 
erators  look  like?  One  such  environment  is  shown  in 
Figure  1.  A  frontend  processes  input  parameters  and 
performs  a  variety  of  manipulations  on  the  input. 

The  second  element  of  the  environment  is  a 
database  or  “model”  which  guides  the  generation  pro¬ 
cess.  One  element  of  the  model  is  a  list  of  the  instance- 
specific  input  parameters  provided  by  the  frontend  - 
the  “catalog”  file.  The  other  two  parts  of  the  model 
contain  information  about  the  entire  family  of  circuit 
designs.  The  declarative  notation  specifies  how  the 
various  representations  of  the  circuit  are  to  be  as¬ 
sembled.  The  leaf  cells  are  the  representation-specific 
primitives  referenced  in  the  notation.  In  the  case  of 
the  layout,  the  leaf  cells  are  simply  the  mask  geome¬ 
tries.  In  the  case  of  the  network  representation,  the 
leaf  cells  may  be  behavioral  models  or  subnetworks  of 
devices. 

The  division  of  information  between  the  declar¬ 
ative  notation  and  the  leaf  cells  is  arbitrary.  Most  of 
the  information  may  reside  in  a  few  leaves,  as  in  the 
case  of  a  network  description  of  a  PLA  that  references 
two  behavioral  models  -  one  for  the  “and”  and  one  for 
the  “or”  plane.  Another  network  description  for  the 
same  family  of  PLAs  may  reference  all  transistors  in 
the  design. 

Finally  there  are  the  circuit  generators  them¬ 
selves,  which  take  the  information  in  the  model  and 
produce  the  representations.  These  programs  are  in¬ 
dependent  of  the  particular  circuit  family,  which  is  de¬ 
scribed  entirely  in  the  declarative  notation  and  the  leaf 
cells.  The  burden  of  circuit  construction  and  analysis 
should  be  placed  on  the  generator  programs.  The  idea 
is  to  keep  the  notation  simple  and  therefore  free  the 


designer  from  u  much  detail  as  possible. 


Output 


Figure  1:  Circuit  Design  Generation 

The  key  to  the  scheme  we  have  proposed  is  the 
development  of  a  declarative  notation.  In  the  remain¬ 
der  of  this  section  we  look  at  languages  that  describe 
multiple  representations  of  circuits  and  outline  our 
own  goals.  In  Section  2,  the  salient  features  of  the 
notation  will  be  presented.  In  Section  3,  the  gener¬ 
ator  programs  will  be  described  in  the  context  of  an 
example. 


1.2  The  Multiple  Representation 
Problem 

The  declarative  description  is  an  example  of  a  hard¬ 
ware  description  language  (HDL).  HDL’s  describe  to 
varving  degrees  functional  behavior,  network  topology 
and  geometrical  structure. 

One  effort  to  represent  behavior,  topology  and 
geometrical  structure  is  Zeus  [Lieberherr  83],  Zeus  is  a 
strongly  typed  procedural  language  that  allows  specifi¬ 
cation  of  both  signal  behavior  as  well  as  floorplanning 
information. 

In  the  functional  programming  language  nFP 
(Sheeran  83]  the  behavior  specification  implies  a  floor- 
plan  and  routing.  Because  of  the  algebraic  proper¬ 
ties  of  nFP,  transformations  can  be  nude  that  retain 
identical  functional  behavior  and  allow  floorplans  and 
routing  to  be  modified.  Another  effort  in  this  direc¬ 
tion  is  CADIC  [Becker  87],  a  system  that  employs  an 
algebraic  notation  for  combining  behavioral  and  rout¬ 
ing  primitives  with  geometrical  operators.  pF P  and 
CADIC  are  both  elegant  synthesis  languages  with  in¬ 
teresting  mathematical  properties.  Our  assumption, 
however,  is  that  the  structure  of  the  circuit  family  is 
already  characterized:  we  desire  an  easy-to-write  no¬ 
tation  that  captures  this  structure. 

1.3  Goals  in  the  Development  of  the 
Notation 

The  declarative  notation  has  four  major  goals. 

L.  Network  Topology  and  Geometric  Structure 
The  notation  must  allow  a  hierarchical  specifica¬ 
tion  of  both  network  topology  and  geometrical 
structure  in  a  way  that  emphasizes  the  correla¬ 
tion  between  the  two  representations.  In  order  to 


nuke  this  correlation  more  apparent  we  avoided 
explicit  representation  of  behavioral  information, 
leaving  it  to  be  specified  in  leaf  cells.  In  contrast, 
languages  such  as  Zeus  include  behavior  explicitly. 

2.  Representation  of  Entire  Circuit  Families 

As  part  of  the  environment  in  Figure  1,  the  nota¬ 
tion  must  allow  sufficient  parametrization  to  de¬ 
scribe  entire  circuit  families.  At  the  minimum  this 
requires  loops  and  conditionals. 

3.  Simplicity  and  Naturalness 

It  is  important  that  designers  be  able  to  cap¬ 
ture  circuit  designs  compactly  and  expressively. 
A  declarative  (as  opposed  to  procedural)  notation 
is  the  obvious  choice. 

4.  Technology  Independence 

One  of  the  major  problems  with  many  powerful 
layout  systems  is  the  technology  dependence  that 
can  creep  in.  Although  elements  of  technology  can 
be  introduced  into  the  notation  (e.g.  in  a  network 
of  MOS  devices),  a  mechanism  should  be  present 
for  hiding  such  details  in  the  leaf  cells.  In  this  way 
the  circuit  features  common  across  technologies 
can  be  emphasized. 

2  Features  of  the  Notation 

2.1  Overview 

The  declarative  notation  consists  of  two  parts:  (1)  a 
declaration,  which  includes  the  name  of  the  circuit, 
the  type  of  the  representation,  a  list  of  parameters; 
and  the  names  of  leaf  cells,  and  (2)  a  collection  of 
statements  used  to  describe  an  entire  circuit  family.  A 
description  can  be  regarded  as  a  set  of  objects  (leaf 
cells  or  abstract  objects)  and  a  set  of  relations  among 
these  objects. 

The  syntax  of  this  high  level  description  is  de¬ 
signed  to  have  expressions  similar  to  those  of  the  “C” 
programming  language.  The  Extended  Backus  Naur 
Formalism  (EBNF)  definition  for  the  declarative  de¬ 
scription  can  be  found  in  [Liem  86], 

2.2  Declaration 

A  simple  declaration  has  the  form: 

■AXE  <circuit_na*e>; 

TYPE  <rsp_type>; 

PARAMETER  <paranstsr_list>; 

LEAF  CELLS  <c#ll_list>; 

<rep_tvpe>  is  a  combination  of  LAYOUT. 
SCHEMATIC,  or  NETWORK.  <par«un#t#r_list>  is 
a  list  of  inputs  to  the  description.  The  values  of 
these  parameters  are  obtained  from  the  catalog  file 
and  serve  to  make  the  description  instance-specific 
<csll_list>  names  all  the  leaf  cells  that  are  used  in 


the  description.  The  leaf  cell  is  the  lowest  level  object 
in  the  hierarchy  of  a  description. 

2.3  Objects 

Leaf  cells  are  the  primitive  objects  on  which  the  oper¬ 
ators  are  applied  and  out  of  which  abstract  objects  are 
built.  For  example,  a  leaf  cell  can  be  the  drawing  of 
a  “nand”  gate  used  for  the  schematic  description  of  a 
decoder  or  it  can  be  the  physical  layout  of  a  half-adder 
used  for  the  layout  description  of  a  multiplier. 

Abstract  objects  are  created  by  combining  leaf 
cells.  An  alias  of  a  leaf  cell,  an  array  of  leaf  cells  or 
a  composition  of  heterogeneous  leaf  cells  are  each  ab¬ 
stract  objects.  Moreover,  an  array  of  abstract  objects, 
a  group  of  heterogeneous  abstract  objects  or  a  com¬ 
position  of  these  two  are  also  abstract  objects.  An 
abstract  object  can  also  be  defined  recursively. 

The  highest  level  of  the  hierarchy  is  a  single  ab¬ 
stract  object  -  the  circuit  that  the  designer  intends  to 
describe.  At  the  lowest  level,  the  circuit  is  a  collection 
of  leaf  cells.  The  description  of  a  circuit  is  thus  hier¬ 
archical  in  nature:  each  abstract  object  is  specified  as 
a  collection  of  lower  level  objects.  Since  an  abstract 
object  may  be  defined  after  it  is  used,  the  description 
of  an  object  promotes  “top-down”  design  or  “stepwise 
refinement”. 


2.4  Operators 

The  operators  which  are  used  in  our  declarative  de¬ 
scriptions  can  be  arranged  in  the  following  groups:  (1) 
connection,  (2)  arithmetic,  (3)  relational,  (4)  logical, 
and  (5)  assignment  (“*”).  The  connection  operators 
take  objects  as  arguments  and  produce  objects  as  re¬ 
sults.  These  operators,  “ — ”,  “1”,  and  “I*”, 

are  used  to  combine  objects  into  more  complicated  ab¬ 
stract  objects. 


A  -  B  A  —  fl  B 


A  1  8  A  I  0  B 

Figure  2:  Geometric  operators  for  combining  objects. 

For  NETWORK  descriptions,  the  connection  op¬ 
erators  are  ail  identical  and  cause  creation  of  an  object 
made  ur»  of  the  argument  objects  connected  according 
to  the  signal  lists  given  with  each  object.  For  exam¬ 
ple,  “A[in,  out]  »  B[in,  aid]  I  CCnid,  out]” 
means  that  “A"  is  made  of  “B"  and  “C”,  with  the 
first  signal  of  “A”  connected  to  the  first  signal  of  “B”, 


the  second  signal  of  “A”  connected  to  the  second  sig¬ 
nal  of  “C” ,  and  the  second  signal  of  “B"  connected  to 
the  first  signal  of  “C”. 

For  LAYOUT  and  SCHEMATIC  descriptions, 
connection  operators  cause  creation  of  an  object  made 
up  of  the  argument  objects  positioned  geometrically. 
These  positions  are  shown  in  Figure  2.  Tne  amount  of 
overlap  for  operators  “ — *”  and  “I*”  is  controlled  by 
attributes  of  the  leaf  cells.  These  operators  are  imple¬ 
mented  within  the  primitives  of  Coordinate  Free  LAP 
[Beckett  85]. 

The  remaining  connection  operators,  mirror  and 
rotate,  act  as  “identity”  operators  in  NETWORK  de¬ 
scriptions. 

Arithmetic,  relational  and  logical  operators  are 
used  as  in  conventional  programming  languages. 

2.5  Control  Constructs 

Two  fundamental  control  constructs  are  provided  to 
enhance  the  expressiveness  of  a  description:  IF  (deci¬ 
sion  making)  and  looping.  IF  is  used  to  specify  con¬ 
ditions.  Looping  is  expressed  in  either  of  two  forms. 
The  first  form  provides  the  number  of  times  for  repeti¬ 
tion;  for  example,  “( —  (X)  (■))*  represents  m  hor- 
izontally  joined  instances  of  X.  The  second  form  pro¬ 
vides  the  upper  bound,  lower  bound  and  step  of  the 
loop  index;  for  example,  “( I  (XCi])  (1*4.  .0,-2))" 
represents  3  instances  of  X,  with  X[4]  situated  at  the 
bottom,  X[2]  in  the  middle,  and  X[0]  on  the  top. 


3  Declarative  Descriptions  of  a 
Decoder 

This  section  provides  examples  of  descriptions  for 
three  circuit  representations  of  a  family  ofprecharged 
decoders  with  n  inputs  and  2n  outputs.  The  descrip¬ 
tions  given  are  for  the  network,  the  layout  and  the 
schematic  diagram.  Two  different  descriptions  are 
given  for  the  network  representation  to  illustrate  the 
manner  in  which  the  notation  facilitates  the  design  ap¬ 
proach  of  step-wise  refinement. 


3.1  Network  Description 

A  network  description  specifies  the  connectivity  be¬ 
tween  a  number  of  hierarchically  structured  objects. 
At  the  lowest  level,  these  objects  are  the  leaf  cells  re¬ 
ferred  to  by  the  description.  Leaf  cells  for  a  network 
description  contain  Network  C  source  code  expressing 
the  behavior  of  the  object  represented  by  the  leaf  cell 
Network  C  (Beckett  86],  or  NC,  is  a  language  similar 
to  C  with  additional  features  to  specify  behavior,  time 
delays  and  connectivity. 

3.1.1  High  level 

The  first  network  description  of  the  decoder  is  a  very 
simple,  high-level  description  (Figure  3). 


files  dacodar;  (t) 

TYPE  IETV0U;  (j) 

P11AXETE1  a;  /•  aaabar  of  iapata  •/  (3) 

LEIF  CELLS  dac.ro*;  (4) 

IfPirr  r,  clock;  (5) 

OUTPUT  y[2**n];  (g) 

<  (7) 

docodarCz,  (8) 

(.  <y[i])  (i»2**a-l . .0)) ,  (9) 

clock  ]  (10) 

■  (I  (dsc.rovfrov,  x,  clock,  y[ro»]])  (11) 

(ro*«2*»a-l. .0));  (12) 

>  (13) 


Figure  3:  High-level  network  description  of  an 
n -input  decoder. 

Since  this  first  network  description  is  at  a  very 
high  level  of  abstraction,  it  uses  only  one  leaf  cell  (line 
4)  and  has  two  levels  of  hierarchy.  The  top  of  the 
hierarchy  -  “dacodar”  -  consists  of  a  set  of  2n  inter¬ 
connected  “dac.ro*”  objects  (lines  11,  12). 

In  addition  to  the  items  in  the  declarative  part 
of  the  layout  and  the  schematic  descriptions,  network 
descriptions  also  have  declarations  of  i/o  signals  (lines 
5,  6)  which  may  be  either  single  signals  or  vectors  The 
output  signal  “y”  is  declared  implicitly  as  a  vector.  A 
vector  is  equivalent  to  a  bus  and  may  therefore  have 
one  dimension  only.  The  number  of  bus  signals  is  given 
in  brackets.  An  automatic  expansion  of  a  vector  takes 
place  if  necessary. 

Sets  of  signals  may  be  specified  using  a  looping 
construct  with  a  comma  as  the  loop  operator  (line  9). 
For  example,  “(,  (y[i])  (i*2**n-l.  .0))”  is  equiv¬ 
alent  to  the  signal  list  “y[2**n-l]  ...,  “y[0]”. 

The  object  “decoder”  has  the  signals  “x”, 
“y[2**n-l]”, ...,  “y[0]”  and  “clock”  in  its  argument 
list.  (Note  that  “x”  is  the  integer  representation  of  a 
bus  of  binary  signals.)  The  argument  list  of  “dec.ro*” 
consists  of  the  variable  “row”  and  the  signals  “x”, 
“clock”,  “yCro*]”.  The  value  of  the  variable  “rox” 
depends  on  the  particular  instance  of  “dec.ro*" . 


d*c.ro»() 

{ 

natwork  trigger  ro*_nr,  in,  elk; 
astaork  aslact; 

if  (elk  “  1  U  row. nr  “*  in)  { 

■«l«ct  ■  0; 

>  win.  { 

select  •  1 

>; 

> 

Figure  4:  The  leaf  cell  deejow ,  referenced  in  Figure 

3. 

The  leaf  cell  “dec.ro*”  is  very  similar  to  an  ordi¬ 
nary  C  function  (Figure  4).  NC  functions  like  this  one 
model  the  behavior  of  some  part  of  a  circuit.  The  vari¬ 
able  type  “network”  is  a  special  NC  data  type  through 


which  signals  are  referenced.  (Ordinary  variables  in 
the  notation,  such  as  “row”,  take  on  specific  values 
when  an  instance  of  an  object  is  generated.  They 
are  also  passed  to  models  as  network  variables.)  Net¬ 
work  variables  are  similar  to  formal  parameters  in  a 
“C”  function  definition.  The  model,  however,  is  in¬ 
voked  only  if  a  variable  declared  as  “network  trigger” 
changes. 

When  the  network  generator  operates  upon  the 
description  in  Figure  3,  a  network  of  2"  instances  of 
“dsc.row”  is  generated.  During  the  NC  simulation 
of  this  network,  the  “network  trigger”  parameters  of 
the  model  (“row.nr”,  “in”,  and  “elk")  receive  their 
values  from  the  leaf  cell  instances  The  model  uses  these 
values  to  compute  the  new  value  for  “select”. 

3.1.2  Low  level 

The  second  network  description  of  the  decoder  (Figure 
5)  is  considerably  more  detailed  than  the  first  one. 
We  have  particularized  the  high  level  description  to 
a  precharged  “nand”  style  decoder.  The  description 
uses  three  leaf  cells  and  has  four  levels  of  hierarchy. 
It  illustrates  in  more  detail  some  of  the  features  of 
the  notation  for  network  descriptions  discussed  in  the 
previous  example. 


■in  dacodar; 

TYPE  IETV01X; 

PJUUnTEt  a; 

LEIF  CELLS  law [la,  oat], 

aval  [clock,  oat], 
pro  [clock,  oat] , 
afat[gata,  aoarca,  drain]; 

IIPUT  x[n] ,  clock; 

OUTPUT  y[2»*n] ; 

VECTOt  r_b[n],  aoda[a]; 

{ 

dacodar[(,  (x[i])  (i«a-1..0)), 

(,  (y[i]>  (i«2**n-l . .0)) ,  clock] 

■  ia_ro*[z,  x.b] 

I  (I  (dac_ro»[row,  x,  x_b,  clock,  y[roa]]) 
(ro»*2**n-l . .0)) ; 

ia_row[x,  z_b] 

■  (I  (in*[x[col],  x_b[col]])  (col«n-l . .0)) ; 

dac_row[row,  x,  x.b,  clock,  sal] 

■  aval [clock,  nods[n-l]] 

I  (I  (sslsctfrov,  col,  x[col],  x_b[col] , 
nods [col] , nods [col-1]])  (col“n-t. .1)) 

I  salact[ro*,0,x[0] ,  x_b[0] ,  noda[0],  aal] 

I  pra [clock,  aal]; 

aalact[ros,  col,  la,  io_bar,  a,  d] 

“  nfst[  in,  a,  d] ,  IF  (2**col)  t  row  !■  0 
*  nfat[ia_bar,  a,  d]  ; 

> 

Figure  5:  Low-level  network  description  of  the 
decoder. 

The  description  specifies  a  network  of  nfet  and 
pfet  devices  in  which  the  behavior  specification  is  re- 


duced  to  that  of  individual  devices,  except  for  the  leaf 
cell  “in"  (A  level  of  description  intermediate  between 
this  and  the  high-level  description  discussed  previously 
would  be  the  definition  of  each  row  as  a  precharged 
“nand”  function  with  appropriate  input  bits  “xCcol]” 
and  “x_bCcol]”.) 

The  scope  of  signal  names  is  local  to  an  object 
definition.  Signals  within  an  object  definition  are  con¬ 
nected  by  name.  For  example,  the  “ssl”  argument 
of  “dsc.ros”  is  logically  connected  to  all  other  occur¬ 
rences  of  “ssl”  in  the  definition  of  “dsc_row” . 

3.2  Layout  Description 

The  layout  representation  in  Figure  6  directs  the  con¬ 
struction  of  a  decoder  whose  floorplan  is  shown  in  Fig¬ 
ure  7.  The  leaf  cells  of  the  description  are  Magic  files 
[Ousterhout  85].  The  layout  generator  produces  a  hi¬ 
erarchy  of  Magic  cells  with  the  decoder  being  the  root 
cell.  These  cells  may  be  used  like  any  other  Magic 
cells,  i.e.  they  may  be  viewed  or  edited  with  Magic  or 
may  be  incorporated  into  a  larger  design. 


fiKI  decoder ; 

TYPE  LAYOUT,  SCHBUTIC; 

PAXAHXTK1  a; 

LIAF  CELLS  route. 1,  Ut[U],  route. r,  «nl  [clock], 

pre [select,  clock],  oaa,  soro; 

IIFUT  xCa] ,  clock; 

OUTPUT  y[2**a] ; 

{ 

decode  r  «  ia.ro» 

I  (I  (doc.ro»[ro»])  (ni  e  l<ea-l.  .41); 

ia_ros  ■  route. 1 

—  ( —  (iavCzCcol]])  (col  •  a-t..O)) 

--  route.r; 

doc.rot[ros] 

*  ovalCclock] 

—  ( —  (soloctCros,  col])  (coloa-l . . 0)) 

—  proCyCros],  clock],  IF  ros  “■  0 

■  o»«l[] 

--  ( —  (soloctCros,  col])  (col"a-l . .0)) 
--  pro [y [rot] ,  ]; 

soloctCros,  col] 

■  oao,  IF  ((Soocol)  k  ros)  !»  0 


cells.  With  these  operators,  cells  are  aligned  so  that 
the  labels  with  the  same  name  are  superimposed. 

A  feature  of  the  notation  not  shown  here  is  the 
ability  to  reference  arrays  of  parameters.  This  feature 
allows  the  construction  of  coded  circuits  like  PLAs  and 
ROMs. 


Figure  7:  Floor  plan  of  the  layout  of  a  three  input 
decoder  produced  by  the  layout  generator. 


3.3  Schematic  Description 


Figure  6;  Layout  description  of  the  decoder. 

An  important  feature  of  the  layout  description 
is  the  application  of  labels.  In  Figure  6  the  formal 
parameters  of  the  leaf  cells  (eg.  “in”  in  “ins”)  refer  to 
labeled  points  in  the  cells.  When  “inv”  is  instantiated, 
a  label  is  created  from  “xCcol]”  and  applied  to  the 
point  labeled  “in’.  These  applied  labels  appear  as 
“x_0”,  “x_l”,  and  “x_2”  in  Figure  7. 

In  this  description  all  of  the  cells  tile  neatly.  The 
notation  is,  however,  sufficiently  flexible  to  accommo¬ 
date  offset  cells  as  well  as  overlapping  ones.  For  this 
purpose,  the  alignment  operators  and  “I*”  are 

used  in  combination  with  labels  present  in  the  leaf 


The  description  in  Figure  6  directs  the  construction 
of  a  schematic  diagram  of  the  decoder,  as  well  as  the 
previously  discussed  layout.  Schematic  output  is  al¬ 
ways  a  picture  and  is  intended  for  documentation  pur¬ 
poses  only.  The  schematic  leaf  cells  are  pictorial  el¬ 
ements  created  with  the  drawing  package  DP  [Giuse 
83].  These  leaf  cells  are  combined  into  a  single  file 
with  appropriate  “placement”  information  in  a  man¬ 
ner  similar  to  the  layout  construction. 

As  in  the  layout,  labels  are  applied  to  the  dia¬ 
gram  through  the  use  of  formal  parameters  passed  to 
the  leaf  cells. 

Figure  8  shows  the  schematic  diagram  of  the  de¬ 
coder  produced  by  the  schematic  generator  from  the 


layout/schematic  description  in  Figure  6. 


clck  clck 


-  -y_3 


.  -  -y_4 


-y_5 


x_2  x_l  x_0 


Figure  8:  Schematic  diagram  of  a  3  inpul  decoder 
produced  by  the  schematic  generator  from  the 
description  of  Fig.  6 


4  Conclusion  and  Future  Work 

The  high  and  low  level  network  examples  illustrate 
the  application  of  the  notation  to  top-down  design 
of  circuit  families.  Noteworthy  is  the  fact  that  both 
the  layout  and  schematic  diagrams  are  generated  from 
the  same  description  (Figure  6).  Also  noteworthy  is 
that  the  low-level  network  description  and  the  lay¬ 
out/schematic  descriptions  share  a  common  hierarchy, 
with  differences  showing  up  at  the  leaf  cell  level:  the 
shared  objects  provide  a  natural  link  between  the  three 
circuit  views. 

We  have  applied  the  notation  to  a  variety  of  de¬ 
coders,  a  family  of  NxM  Baugh-Wooley  multipliers, 
and  a  multiplier  employing  redundant  binary  repre¬ 
sentations  of  terms.  A  graduate  VLSI  design  class  has 
employed  the  notation  in  the  design  of  modules  com¬ 
prising  a  message  routing  chip,  in  particular  a  variable 
width,  variable  depth  FIFO.  The  notation  has  demon¬ 
strated  utility  both  as  a  means  of  capturing  informa¬ 


tion  about  circuits  at  a  variety  of  levels,  and  as  an 
intermediate  database  in  a  design  generator  environ¬ 
ment. 

A  major  extension  to  the  notation  would  be  the 
addition  of  a  more  flexible  interconnect  strategy  for  as¬ 
sembling  the  layout.  In  many  cases  the  requirement  of 
interlocking  leaf  cells  is  a  severe  constraint.  By  adding 
more  analysis  of  cell  borders  in  the  layout  generator, 
cell  extensions  as  well  as  routing  could  be  employed  to 
place  and  interconnect  cells. 
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